System and method for creating and accessing outgoing telephone call log

ABSTRACT

Outgoing call log data associated with a call from a subscriber&#39;s terminal is provided by a system including a switch, which receives the call from the subscriber&#39;s terminal and launches a query in response to the call, and a service controller, which receives the query and forwards call data to an interface server in response to the query. The switch continues to process the telephone call after querying the service controller. The interface server obtains additional information from a directory database based on at least the received call data. An outgoing call log database receives and stores the call data and the additional information from the interface server as the outgoing call log data. A web server retrieves the outgoing call log data from the outgoing call log database, in response to a query from a web client, and displays the outgoing call log data at the web client.

The present application is a continuation application of pending U.S.patent application Ser. No. 11/106,522 filed on Apr. 15, 2005, which isa continuation of U.S. patent application Ser. No. 09/917,747, filed onJul. 31, 2001, now issued U.S. Pat. No. 6,904,137, the disclosures ofwhich are expressly incorporated herein by reference in their entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the field of telecommunications. Moreparticularly, the present invention relates to automatically creating alog of outgoing telephone calls from a subscriber's telephone andstoring outgoing call log data in a database, which is accessible by thesubscriber over a data network for displaying the outgoing call log dataand generating associated reports.

2. Acronyms

The written description provided herein contains acronyms which refer tovarious telecommunications services, components and techniques, as wellas features relating to the present invention. Although some of theseacronyms are known, use of these acronyms is not strictly standardizedin the art. For purposes of the written description herein, the acronymsare defined as follows:

-   Advanced Intelligent Network (AIN)-   Graphical User Interface (GUI)-   Generic Data Interface (GDI)-   HyperText Mark-Up Language (HTML)-   HyperText Transfer Language Protocol (HTTP)-   Java Database Conductivity (JDBC)-   Lightweight Directory Access Protocol (LDAP)-   Line Information Database (LIDB)-   Off-Hook Delay (OHD)-   Outgoing Call Log (OCL)-   Open Database Connectivity (ODBC)-   Personal Call Manager/Personal Communications Manager (PCM)-   Personal Identification Number (PIN)-   Public Switched Telephone Network (PSTN)-   Service Control Point (SCP)-   Service Switching Point (SSP)-   Signaling System 7 (SS7)-   Signaling Transfer Point (STP)-   Transmission Control Protocol/Internet Protocol (TCP/IP)

3. Background Information

Presently, a number of advanced intelligent network (AIN) basedtelecommunications services enable dynamic interaction between thecustomers and their respective service accounts. Servers, databases,intelligent peripherals and other external data network elementsinterface with the public switched telephone network (PSTN) to processand store information created during routine handling of telephonecalls. For example, names may be associated with incoming calling partynumbers using an external directory database while the PSIN isprocessing the call. The name, telephone number and other call specificinformation may then be stored in an external database for access by thecustomer.

However, no service makes information related to outgoing telephonecalls placed from a customer's telephone readily accessible to thecustomer for extensive processing and practical use. Although somepresent applications store outgoing telephone call data, the data is notused for detailed historical call tracking, report generation and othersubstantive processing. For example, in DEFAZIO et al., U.S. Pat. No.5,940,484, outgoing call data automatically populates atelecommunications service related database. The database issubsequently used to increase the efficiency of associating names withincoming calls to the customer's telephone number, relying on thegeneral theory that the parties called by the customer are the partiesmost likely to call the customer. The name database of DEFAZIO et al. iskept current by eliminating, for example, telephone numbers that havebeen changed with respect to a particular party or have not been calledfor an extended period of time.

DEFAZIO et al. does not teach, however, processing the outgoing calldata to maintain a detailed historical record of outgoing calls or toenable generation of outgoing call reports. Furthermore, the data storedfor each call is too general to enable any effective analysis. Forexample, DEFAZIO et al. simply retains the number of total calls to (andfrom) a particular telephone number and the date of the most recentcall.

The present invention overcomes the problems associated with the priorart, as described below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is further described in the detailed descriptionthat follows, by reference to the noted plurality of drawings by way ofnon-limiting examples of preferred embodiments of the present invention,in which like reference numerals represent -similar parts throughoutseveral views of the drawings, and in which:

FIG. 1 is a block diagram illustrating system components, according toan aspect of the present invention;

FIG. 2 is an exemplary call flow diagram illustrating the process ofaccessing and storing outgoing call data in an OCL database, accordingto an aspect of the present invention;

FIG. 3 is an exemplary call flow diagram illustrating the process ofaccessing and interacting with the OCL database via the Internet,according to an aspect of the present invention;

FIG. 4 is an exemplary outgoing call log window displaying called partyinformation for a selected account number at the subscriber's personalcomputer, or other graphical user interface, according to an aspect ofthe present invention; and

FIG. 5 is a block diagram illustrating system components, including aninteractive voice response, according to an aspect of the presentinvention.

DETAILED DESCRIPTION OF EMBODIMENTS

In view of the above, the present invention through one or more of itsvarious aspects and/or embodiments is presented to accomplish one ormore objectives and advantages, such as those noted below.

An aspect of the present invention provides a system for providingoutgoing call log data associated with a telephone call from asubscriber's telephone. The system includes a switch that receives thetelephone call from the subscriber's telephone and a service controlpoint that receives the query from the switch and forwards call data inresponse to the query. The switch includes an advanced intelligentnetwork (AIN) trigger set to launch a query in response to the telephonecall and may continue to process the telephone call after launching thequery to the service control point. The system further includes aninterface server that receives the call data from the service controlpoint and obtains additional information from a directory database basedon at least the received call data; an outgoing call log database thatreceives and stores the call data and the additional information fromthe interface server as the outgoing call log data; and a web serverthat retrieves the outgoing call log data from the outgoing call logdatabase, in response to a query from a web client, and displays theoutgoing call log data at the web client.

The call data received by the interface server includes at least acalled party number, although the call data may also include a callstart data, a call start time, a call stop date and a call stop time.The interface server may calculate a call duration based on the calldata. The call log data received and stored by the outgoing call logdatabase would further include the call duration. The interface servermay receive additional information, including at least a called partyname corresponding to the called party number. The web server may thendisplay at the web client at least the called party name, the calledparty number and the call duration.

In an aspect of the present invention, the system for providing outgoingcall log data further includes the web server enabling the subscriber toinitiate a repeat telephone call to the called party number by selectingthe called party number from the display at the web client. The webserver may store at least the called party name and the called partynumber in a personal directory database of the subscriber in response tothe subscriber selecting the called party number from the display at theweb client. The web server may also generate a report based on at leastthe outgoing call log data and display the report at the web client.

Another aspect of the present invention provides a system for providingan outgoing call log report based on multiple telephone calls from asubscriber's telephone. The system includes a first data network thatreceives from a public switched telephone network (PSTN) call datacorresponding to the multiple telephone calls placed from thesubscriber's telephone in the PSTN. The first data network includes aninterface server that receives the call data from the PSTN through adata interface and obtains additional information from a directorydatabase corresponding to the call data, as well as an outgoing call logdatabase that stores outgoing call log data, which includes acorresponding one of the call data and associated additional informationreceived from the interface server. In an embodiment of the invention,the directory database is included in the PSTN.

The system further includes a second data network, which includes a webserver. In response to a query from a web client, the web serverretrieves the outgoing call log data from the outgoing call logdatabase, generates a report based at least on the outgoing call logdata and displays at least the generated report at the web client. Thesecond data network may include the Internet.

The additional information obtained by the interface server from thedirectory database may include multiple called party names associatedwith the call data received from the PSTN. Also, the data received bythe interface server from the PSTN may include a called party number, astart date, a start time, a stop date and stop time associated with eachof the multiple telephone calls from the subscriber's telephone. Theinterface server calculates a call duration associated with each of themultiple telephone calls from the subscriber's telephone. The outgoingcall log data stored by the outgoing call log database may then furtherinclude the call duration for each of the plurality of telephone calls.

Another aspect of the present invention provides a method for providingoutgoing call log data associated with a telephone call from asubscriber's telephone. The method includes launching a query from aswitch in response to a preset AIN trigger. The query relates to thetelephone call from the subscriber's telephone and is received at aservice control point. The call data is related to the telephone calland may include a called party number. The call data is forwarded to aninterface server via a data interface. Additional information from adirectory database is retrieved based on at least the call data, and mayinclude a called party name. At least the call data and the additionalinformation are stored in an outgoing call log database as the outgoingcall log data. The outgoing call log data is provided from the outgoingcall log database to a web server in response to a query from a webclient associated with the subscriber. The outgoing call log data issent to the web client. Furthermore, the telephone call may continue tobe processed after launching the query to the service control point.

The method may also include calculating a call duration based on thecall data received by the interface server. The call data would furtherinclude a call start date, a call start time, a call stop date and acall stop time. The additional information received by the interfaceserver may also include at least a called party name corresponding tothe called party number. The called party name, the called party numberand the call duration may be displayed at the web client. Also, a repeattelephone call to the called party number may be initiated by selectingthe called party number from the display at the web client. The calledparty name and the called party number may be stored in a personaldirectory database of the subscriber by selecting the called party namefrom the display at the web client. Also, an outgoing call log reportmay be generated based on at least the outgoing call log data. Theoutgoing call log report is displayed at the web client.

Another aspect of the present invention provides a method for providingoutgoing call data associated with a telephone call from a subscribertelephone to a called party where the outgoing call data is providedover multiple networks to the subscriber at a graphical user interface.The method includes storing the outgoing call data in an outgoing calllog database in response to the telephone call from the subscribertelephone; receiving a query from the subscriber through at least one ofthe multiple networks; retrieving the outgoing call data from theoutgoing call log database in response to the query; and transmittingthe outgoing call data to the subscriber through at least two of themultiple networks. At least one of the multiple networks may include apacket switched data network and at least one of the packet switcheddata networks may be the Internet.

An AIN trigger may be initially launched when the telephone call fromthe subscriber telephone is placed. The storing of the outgoing calldata is then initiated in response to the AIN trigger. It may first bedetermined whether the subscriber has activated a service for providingthe outgoing call data.

The storing of the outgoing call data may further include obtaining, ata service control point, called party data from a service switchingpoint. The called party data includes at least a telephone numberassociated with the called party. The called party data is transmittedfrom the service control point to a server by way of a GDI client.Additional information associated with the called party data is obtainedfrom a directory database. The additional information includes at leasta name associated with a telephone number of the called party. Thecalled party data and the additional information is transmitted from theserver to the outgoing call log database and stored as the outgoing calldata.

The present invention is an AIN based telecommunications system andmethod that enables an outgoing call log (OCL) service. The outgoingcall log is accessible through the PSTN, as well as data communicationnetworks, such as the Internet and other packet switched type networks.The outgoing call log is automatically populated by called party datawhenever a call is placed in the PSTN from an OCL subscriber'stelephone. The outgoing call log is interactively accessible through agraphical user interface (GUI) by the subscriber over the Internet, forexample, enabling the subscriber to review the data, generate reports,add entries to a personal directory and place repeat telephone calls.

FIG. 1 illustrates an exemplary telecommunications network (e.g., thePSTN) in association with the present invention. The exemplary networkincludes a subscriber telephone 10 (i.e., the calling party telephone),an originating service switching pont (SSP) 14, a terminating SSP 16 anda called party telephone 12. The network also includes a conventionalsignaling transfer point (STP) 32 and service control point (SCP) 30. Byway of example, the SCP 30 may be implemented with the BellcoreIntegrated Service Control Point, loaded with ISCP software Version 4.4(or higher), available from Telecordia, Murray Hill, N.J.

The SSP 14 is the originating central office (CO) for the subscribertelephone 10 and the SSP 16 is the terminating CO for the called partytelephone 12. However, the terminating CO and the originating CO may bethe same, or there may be any number of intervening switches routing theconnection between the subscriber telephone 10 and the called partytelephone 12. The SSPs 14 and 16 include, for example, 1AESS or 5ESSswitches manufactured by Lucent Technologies, Inc., or DMS-100 switchesmanufactured by Nortel Networks Corporation (Nortel), or AXE-10 switchesmanufactured by Telefonaktiebolaget LM Ericsson.

The 1AESS switches may use an AIN Release 0.1 protocol and should beequipped with Generic 1AE13.01 (or higher) software and associated AINSSP features. The 5ESS switches may utilize an AIN Release 0.1 protocoland should be equipped with Generic 5E12 (or higher) software andassociated AIN SSP features. The DMS-100 switches (release NA009) mayutilize an AIN Release 0.1 protocol and associated AIN SSP features. TheAXE-10 switches may utilize an AIN Release 0.1 protocol and should beequipped with Generic 8.07 (or higher) software and associated AIN SSPfeatures. The call service logic of the present invention may beupgraded to accommodate future AIN releases and protocols and futuretrigger types. Specifications of AIN Release 0.1 SSPs may be found inBellcore TR-NWT-001285, Switch-Service Control Point ApplicationProtocol Interface Generic Requirements, the disclosure of which isexpressly incorporated by reference herein in its entirety.

FIG. 1 further depicts an exemplary data network, associated with thetelecommunications network described above, that includes a web client20, connectable through the Internet 40, or other packet switched datanetwork, to a web server 42. The web client 20 includes a GUI 22 andassociated operating software 24. FIG. 1 indicates the web client 20being directly connected to the Internet, for example, through a digitalsubscriber line (DSL) or integrated services digital network (ISDN)digital connection. However, any conventional Internet access may beused, including an analog dial-up connection, through a modem (notpictured) on the subscriber's telephone line and the SSP 14.

The data network also includes an OCL server 34, which is an interfaceserver connected to the SCP 30 through, for example, a Bellcore GenericData Interface (GDI) client 31. Generally, the OCL server 34 interfaceswith the GDI client 31, facilitating communication between the PSTN andthe data network. Both the web server 42 and the OCL server 34 areconnected to an OCL database 36 within the data network. The OCLdatabase 36 is a standard relational database, such as those availablefrom Oracle Corporation or Sybase, Inc., and contains accountinformation and call log data of the outgoing call log subscribers. TheOCL server 34 is also connected to a directory database 38 (i.e., a nameand number database), which includes the applicable universe oftelephone numbers and associated names in at least a portion of thePSTN. Although not shown, the SCP 30 can be directly connected to thedirectory database 38 instead of through the OCL server 34. Thedirectory database 38 may be a line information database (LIDB), whichis maintained independently of the PSTN and updated appropriately by theservice provider to assure provision of current information. Theinvention may include any comparable publicly or privately maintaineddatabase, including a Lucent LDAP database and server.

When accessing outgoing call information using the Internet, thesubscriber accesses the web server 42 using the GUI 22, which may be,for example an IBM Pentium based personal computer running MicrosoftWindows operating system, available from Microsoft Corporation, Inc. Inan embodiment, the web client software 24 incorporates a web browser,such as Microsoft Internet Explorer, Netscape Navigator or HotJava,available from Sun Microsystems, Inc. An embodiment of the inventionwith respect to the web server 42 includes running Linux or MicrosoftWindows operating system and Apache web server software, available fromthe Apache Software Foundation, or Jigsaw web server software, availablefrom World Wide Web Consortium (W3C).

FIG. 2 is an exemplary call flow diagram depicting the subscriberplacing a call from subscriber telephone 10 and thus automaticallyinvoking the outgoing call log service. As shown at step 102, thesubscriber telephone 10 is connected to the local SSP 14 whenever thesubscriber telephone 10 goes “off-hook,” (i.e., the handset is removedfrom the cradle or is otherwise activated to receive a dial tone). Theoutgoing call log service is initiated at this point by an AIN off-hookdelay (OHD) trigger, which has been previously set in SSP 14 uponservice activation. The SSP 14 launches the OHD trigger each time thesubscriber phone goes off-hook and a series of digits adhering to theswitch's dial plan is dialed.

At step 104, the OHD trigger activated by the SSP 14 causes call data tobe sent to the SCP 30 for processing, via the existing signaling system7 (SS7) network (and appropriate STP 22), in a known manner. The calldata includes the called party number and the calling party number.

Significantly, the telephone call is not suspended at the SSP 14 switchduring execution of the outgoing call log service. Rather, the callcompletes in a normal fashion based, in part, on any instructions fromthe SCP 30 at step 105 to the originating SSP 14, and/or the terminatingSSP 16 (not shown in FIG. 2). For example, the subscriber and the calledparty may subscribe to additional AIN based telephony services that maybe activated by call placement or receipt. These services would continueto be processed during execution of the outgoing call log service. Thecall is completed at step 106, connecting the subscriber telephone 10with the called party telephone 12 through at least the originating SSP14.

While the telephone call is being processed and routed, the SCP 30interfaces with the data network, which functions separately from thePSTN. In an embodiment of the invention, the interface between the SCP30 and the data network is the Bellcore GDI client 31. This interfaceprovides the capability to send and receive transactions to and fromexternal systems using known transmission control protocol/internetprotocol (TCP/IP) with transaction capabilities application part (TCAP)messages. The GDI client 31 therefore enables the SCP 30 to generatemessages to request data, send data or invoke an application (InvokeApp)to the OCL server 34.

As shown in step 108 of FIG. 2, the SCP 30 sends an InvokeApp message tothe OCL server 34 via the GDI client 31 (not pictured in FIG. 2). TheInvokeApp message may include the calling party number, the called partynumber, the call type and the call date and time. As stated above, byinvoking an interface server external to the PSTN, the SCP 30, the SSP14 and other PSTN resources may continue processing the call withouthaving to await execution of the outgoing call log service.

When the OCL server 34 receives the InvokeApp message from the SCP 30via the GDI client 31, it first confirms at step 110 that the outgoingcall log service is active. Ordinarily, the outgoing call log service iscontinually active from the time the service is implemented on behalf ofthe subscriber. However, in an embodiment of the invention, thesubscriber may selectively activate and deactivate the outgoing call logservice as desired, using the web client 20 via the Internet 40, asdiscussed below, or using a conventional dual tone multi-frequency(DTMF) telephone via an interactive voice response (IVR) system, asdiscussed, for example, in U.S. patent application Ser. No. 09/619,312,filed on Jul. 19, 2000, the disclosure of which this application herebyincorporates by reference in its entirety. By confirming an activestatus, the OCL sever 34 avoids unnecessary processing time in the eventthe service has been discontinued or is temporarily OFF.

The confirmation step 110 is an interaction between the OCL server 34and the OCL database 36. The OCL database 36 contains data relating tothe subscriber's account, including an active/inactive status indicatorand the outgoing call log itself. The OCL server 34 and the OCL database36 communicate with one another using Java database connectivity (JDBC),although any appropriate interface may be used, such as open databaseconnectivity (ODBC). The OCL server 34 queries the OCL database 36 forstatus information. An inactive indication terminates the outgoing calllog process.

The OCL server 34 also interfaces with the directory database 38 at step112 to determine the name associated with the called party numberprovided by the SCP 30 at step 108. As discussed above, the directorydatabase 38 may be an external LIDB maintained independently of the PSTNand updated appropriately by the service provider to assure currentinformation. Alternatively, the directory database 38 may be a publiclymaintained database that is part of the PSTN. Once the called party nameis retrieved from the directory database 38, the OCL server 34 instructsthe OCL database 36 to store the call related information in associationwith the subscriber's account, including the called party number, theretrieved called party name and the time and date the call was placed.

In one embodiment of the invention, the outgoing call log service isimplemented along with a personal directory service, such as thepersonal directory service described, for example, in conjunction withPersonal Call Manager (PCM), as disclosed in U.S. patent applicationSer. No. 09/619,312, filed on Jul. 19, 2000. A subscriber's personaldirectory includes at least names and telephone numbers that thesubscriber has elected to enter into a personal database, which may bestored at another external database accessible by the OCL server 34, aswell as the web server 42. If the OCL server is unable to retrieve aname associated with a called party number from the directory database38 (e.g., the called party is located in a region outside the scope ofthe particular directory database), the OCL server 34 is able to querythe personal directory database as a secondary attempt to retrieve thename associated with the called party number. Alternatively, because ofthe likelihood that the subscriber is calling someone already in thepersonal directory, the OCL server 34 may query the personal directorydatabase before querying the directory database 38 to obtain the calledparty name. By querying the personal directory database first, the OCLserver 34 may possibly avoid the step of communicating with thedirectory database 38 altogether, thus increasing processing efficiency.Furthermore, the name retrieved from the personal directory databasewould reflect the subscriber's customized preference, so that theoutgoing call log would include terms, such as “dad,” opposed toimpersonal, proper names for close friends and family members.

Alternative embodiments of the invention combine the various server anddatabase functions described above into any practical combination ofPSTN and data network systems. For example, the directory database 38,i.e., the LIDB, may be internal to the SCP 30. One advantage of aninternal directory is that the PSTN provider would have theresponsibility of maintaining a current database of names associatedwith the applicable universe of telephone numbers. In this embodiment,the called party name would be among the information in the InvokeAppmessage sent by the SCP 30 to the OCL server 34, via the GDI client 31,at step 108 of FIG. 2. Obviously, the OCL server 34 would then skipquerying the directory database 38 at step 112. Alternatively, the OCLserver 34 could store the information of the directory database 38 (aswell as the OCL database 36) in an internal memory, depending on thedemands of the service and limitations of the OCL server 34. Otherwise,the SCP 30 could communicate directly with the directory database 38 toobtain the information.

Moreover, the functions of the OCL server 34 and/or the OCL database 36may be performed entirely by the SCP 30, thereby eliminating the needfor the corresponding external network elements and promoting efficiencyof the outgoing call log process. However, the SCP 30 would incur theadditional burden of processing the outgoing call log service, includingassociating names and telephone numbers, adding new entries to theoutgoing call log and interfacing with the subscriber via the Internet.Interfacing with the subscriber would require additional networkresources, such as an intelligent peripheral to translate data messagesinto a standard protocol, e.g., SR-3511, and otherwise enablecommunication between the web server 42 and the SCP 30.

When the call is terminated, the SSP 14 activates an appropriatesignaling message, such as an intelligent network disconnect trigger,which is sent to the SCP 30 at step 120. The SCP 30 notes the date andtime of call termination and passes this information to the OCL server34 via the GDI client 31 at step 122. The OCL server 34 calculates thecall duration and sends the stop date, the stop time and the calculatedcall duration to the OCL database 36. The OCL database 36 stores theinformation in the subscriber's account, along with the associated startdate, start time and called party name and number, previously stored bythe OCL database 36.

According to the invention, the subscriber is able to access his or heroutgoing call log data stored in the OCL database 36 through a datanetwork, independently of PSTN involvement. FIG. 3 is an exemplary callflow diagram depicting an embodiment of the invention in which thesubscriber accesses the outgoing call log data over a packet switcheddata network using the GUI 22 of web client 20. At step 202, thesubscriber accesses the web server 42 through the Internet 40 from theweb client 20, using a web browser such as Microsoft Internet Explorer,Netscape Navigator or HotJava. The web server 42 serves as a secureaccess platform, receiving hypertext transfer language protocol (HTTP)messages from the web client 20 and providing hypertext mark-up language(HTML) web pages in response to the subscriber's input. The web pagesrelate to the subscriber's outgoing call log service account, an exampleof which is depicted in FIG. 4, discussed below. In alternativeembodiments of the invention, the subscriber may connect to the OCLdatabase 36 from web client 20 or through the OCL server 34 or anynumber of intervening web servers.

Once connected to the web server 42, the subscriber accesses the OCLdatabase 36 in order to log-in to the subscriber's personal outgoingcall log service account. The log-in process may include authenticationof the subscriber to protect the privacy of the subscriber's outgoingcall information. To perform the authentication, the web server 42contacts the OCL database 36 at step 204, which recognizes the accessrequest. The OCL database 36 retrieves the subscriber's accountinformation, which includes the authentication data, and sends theaccount information to the web server 42 for processing at step 206. Theauthentication data may include the subscriber's name, account number,personal identification number (PIN) and/or password.

In an alternative embodiment, the subscriber's authentication data isstored at an authentication/subscription information (ASI) serverseparate from the OCL database 36. Implementation of the separate ASIserver enables the telecommunications service provider to consolidateauthentication processing of a variety of telecommunications services.For example, the outgoing call log service may be offered as part of, orin addition to, a PCM service, as discussed for example in U.S. patentapplication Ser. No. 09/619,312, filed on Jul. 19, 2000. A shared ASIserver reduces redundant data storage and otherwise promotes processingefficiency of all of the services involved.

Upon receiving the authentication data from the OCL database 36, the webserver 42 prompts the subscriber to enter the matching data from the webclient 20 at step 208 of FIG. 3, which indicates an ongoing interactionbetween the web server 42 and the web client 20. In other words, the webserver 42 causes the display of various web screens at the GUI 22 of theweb client 20, to which the subscriber responds. When the entered datadoes not match the stored authentication data, the web server 42 deniesaccess to the requested account, possibly after allowing repeatattempts, depending on the programming choices of the service provider.

When the entered data matches the stored authentication data, the webserver 42 queries the OCL database 36 at step 212 and retrieves thesubstantive outgoing call log data associated with the subscriber'saccount at step 214. The web server 42 displays consecutive web screensindicating the outgoing call log service and displaying the subscriber'spersonalized data. The subscriber can thus interact with his or heroutgoing call log service account, indicated by step 218. Alternatively,the web server 42 retrieves the authentication data and the substantiveoutgoing call log information in a single step to eliminate, forexample, processing steps 212 and 214, although the outgoing call loginformation is not provided to the web client 20 until after successfulsubscriber authentication. The process indicated by FIG. 3 enables thesubscriber to access the outgoing call log information from any locationwith networking facilities that allow connection to the data network,whether it is the Internet, a corporate intranet or other TCP/IPnetwork.

As discussed above, in an embodiment of the invention, the subscriber'saccount information, including names and telephone numbers of theoutgoing call log entries, are stored at the SCP 30. From a subscriberinteraction standpoint, however, a separate, external OCL database 36would likely function more efficiently. For example, the subscriber mayaccess account information without waiting for availability of the SCP30, which may be handling numerous telephone calls and other traffic inthe PSTN environment.

An exemplary customized outgoing call log web screen 300 is depicted inFIG. 4. The outgoing call log web screen includes a table 302 with ninevertical columns to accommodate various call data. The first threecolumns contain the first and last names of the called party and thecorresponding telephone number, indicated by 310, 312 and 314,respectively. The names appear as they are stored in the directorydatabase 38 or the personal directory database from which the OCL server34 originally retrieved the party name during call placement based onthe telephone number. In an embodiment of the invention, the web screen300 includes another column entitled “comments,” for example, in whichthe subscriber is provided additional information about each listedparty retrieved, for example, from the personalized directory database,described above.

The fourth and fifth columns of the table 302 contain the start date 316and the start time 318 of the outgoing telephone call. Similarly, thesixth and seventh columns contain the stop date 320 and the stop time322 of the same telephone call. The duration 324 of the call issummarized at the next column for the subscriber's convenience. The callduration is retrieved from the OCL database 36, although alternatively,the web server 42 may calculate the call duration from the retrievedstart and stop data, in the event the OCL server 34 has not beprogrammed to calculate call duration prior to sending the stop date andtime to the OCL database 36 at step 124 of FIG. 2. The call durationrelated information is displayed in columns 316 to 324 to provide thespecific call history to the subscriber.

The outgoing call data enables the creation of call reports, which thesubscriber may request through the web server 42. Such call reportsinclude, for example, a summary of calls to a particular number and theassociated charges, if available from the service provider. Call reportsmay also include various combinations and summaries of all outgoing callinformation, in the form of graphs, pie charts, bar charts and the like.For example, a report format may present a pie chart showing theproportion of calls to particular telephone numbers over a specifiedperiod of time. Another report format may present a graph indicatinglocal versus long distance calls.

With respect to the extent of reports available, the service providermay offer incremental levels of outgoing call log service privileges.For example, a basic outgoing call log service includes only theinformation in the table 302 of FIG. 4 with no report generatingcapability. A mid-range service includes minimal reports, such assummaries of call data to a particular telephone, and other standardreports. A deluxe outgoing call log service provides a fill range ofreports and graphics, including the ability to create customized reportshaving subscriber directed formats.

The final column shown in the table 302 is the delete column 326. Thesubscriber simply indicates the desired deletion of a line entry byselecting the delete button in the delete column 326, or otherwisehighlighting the delete button. Once the subscriber has selected theentries to deleted, he or she selects box 332, entitled “delete selectedentries” to remove the selected line items from the table 302. When thesubscriber wants to delete all entries in the table 302, he or shealternatively selects box 330, entitled “delete all entries.” If nodelete command is executed by the subscriber, the outgoing call log dataremains in the table 302 and will continue to be displayed pursuant tofurther request data commands until a delete command is sent or untilsome predetermined drop time expires, for example, 30 days. In oneembodiment, the drop time may be adjusted by the subscriber. Also, theline entries in table 302 are eliminated in chronological order as thetable 302 reaches a predetermined maximum capacity, such as 100 lineentries.

Note that deleting entries from the outgoing call log table 302 may notdelete the corresponding data from the OCL database 36 or the historicalcalling record, which would require a separate command from thesubscriber. Although not indicated at web screen 300, the outgoing calllog service maintains a record of the duration related data of alloutgoing telephone calls at the OCL database 36 until a predeterminedperiod of time has elapsed, e.g., three months, or the subscriberchooses to delete the information. Saving the information enablesgeneration of outgoing call data reports, discussed above.

Block 340 of FIG. 4 provides a series of six option indicators.Selection of an option indicator retrieves another web screen from theweb server 42 for display at the web client 20. The specific optionsavailable to the subscriber depend on the level of service to which thesubscriber subscribes, as discussed above. For example, the deluxeoutgoing call log service may include changing authentication data(e.g., the subscriber password) as option 1, activating and deactivatingthe outgoing call log service as option 2, reviewing historical outgoingcall records as option 3, creating standard outgoing call reports asoption 4, and creating customized outgoing call reports as option 5.Option 6 may provide, for example, links to other personal AIN basedcall services of the subscriber, such as a personal directory, or returnto a PCM home page or menu.

The web screen 300 of FIG. 4 further includes instructions to thesubscriber in regard to the entries in table 302. For example,instruction 341 states, “Click on the Telephone Number to Dial Again.”Following this instruction, the subscriber may initiate a telephone callto a telephone number indicated in column 314 by simply clicking on thenumber. Using known techniques, the web server 42 then initiates aconnection over the PSTN from the subscriber telephone 10 or over theexisting data network connection from the web client 20 using, forexample, Voice Over Internet capability. Instruction 342 states, “Clickon the Name to add to Personal Directory.” Following this instruction, asubscriber who also has personal directory privileges from the serviceprovider may add the name and telephone number of a line item from table302 to the personal directory. Additional instructions may be displayedon web screen 300, for example, enabling the subscriber to populate adatabase dedicated to personal digital assistant (PDA), e.g., a PalmVIIx, available from Palm, Inc., with the outgoing call log data.

In another embodiment of the invention, the subscriber's personaldirectory may be populated automatically by the outgoing call logservice. For example, the OCL server 34 is programmed to track thenumber of times called party numbers are dialed from the subscribertelephone 10. When a particular called party number is identified asbeing called frequently, e.g., at least three times within apredetermined time period, the OCL server 34 accesses the databasecontaining the subscriber's personal directory and adds the frequentlycalled telephone number and associated name, unless they are alreadylisted. The web screen 300 may then include, for example, an instructionenabling the subscriber to view the list of newly added frequentlycalled telephone numbers.

As stated above, an embodiment of the invention enables the subscriberto access the outgoing call log service via an IVR, as well as via theInternet, thereby greatly increasing flexibility and convenience. FIG. 5is a block diagram illustrating exemplary system components, includingan IVR 45. The other PSTN and data network components depicted in FIG. 5are the same as those previously discussed in regard to FIG. 1. The IVR45 is connected to the SSP 16 and the OCL server 34, enabling access tothe OCL database 36 from the subscriber telephone 10. The IVR 45 may be,for example, available under the trademark CONVERSANT System for IVR,Version 6.0, Update 1, provided by Lucent Technologies, Inc. The networkalternatively incorporates any compatible stand-alone IVR or advancedintelligence network-intelligent peripheral (AIN-IP or intelligentperipheral) providing an IVR.

Access to the outgoing call log service through the IVR 45 is limited inthat the subscriber cannot create reports, for example. However, thesubscriber can access many features of the outgoing call log service,including audibly reviewing basic outgoing call log data, changingauthentication data (e.g., the subscriber password) and activating anddeactivating the outgoing call log service.

To use the IVR, the subscriber calls a predetermined telephone number,e.g., a toll free number, from any DTMF telephone, such as thesubscriber telephone 10. The subscriber thus accesses the IVR 45 throughconventional switches, such as SSP 14 and SSP 16. The IVR 45 receivesthe call and initiates a request for various authentication information,including account number, PIN and/or password. These numbers coincidewith the authentication data used to access the outgoing call logservice via the Internet 40, as described above. The pre-programmedvoice announcements reside in the IVR 45, the implementation of which iswell known. The authentication data is provided by the subscriber usingthe touch tones of the subscriber telephone 10. The IVR 45 forwards theinformation to the OCL server 34, which queries the OCL database 36 forverification.

After verification, the OCL server 34 retrieves the current data for theoutgoing call log service, including generally the information shown intable 302 of FIG. 4, and provides the data to the IVR 45. The IVR 45verbally recites a menu of options to the subscriber, which may includechanging authentication data, toggling the service ON and OFF andreceiving outgoing call data. The subscriber listens to the options andinputs the selections via the telephone touch tone key pad. If thecommand includes receiving the outgoing call data, the IVR 45 providesan abbreviated listing of data, as dictated by system capabilities, thatincludes, for example, called telephone numbers and corresponding datesand times for call duration. In an embodiment, the IVR 45 may beprogrammed to request a specific telephone number and provide thecorresponding call data for the subscriber to review. Any changes to thedata are forwarded from the IVR 45 to the OCL server 34, which updatesthe OCL database 36, if necessary.

The IVR 45 may be incorporated into the outgoing call log service asshown, for example, in U.S. patent application Ser. No. 09/619,312,filed on Jul. 19, 2000. If the functionality of the OCL server 34 and/orthe OCL database 36 resides in the SCP 30, the IVR 45 may beincorporated into an intelligent peripheral, which interfaces with theSCP 30 using SR-3511 protocol signaling or the like. The form ofimplementation would be invisible with respect to subscriberinteraction.

Although the invention has been described with reference to severalexemplary embodiments, it is understood that the words that have beenused are words of description and illustration, rather than words oflimitation. Changes may be made within the purview of the appendedclaims, as presently stated and as amended, without departing from thescope and spirit of the invention in its aspects. Although the inventionhas been described with reference to particular means, materials andembodiments, the invention is not intended to be limited to theparticulars disclosed; rather, the invention extends to all functionallyequivalent structures, methods and uses such as are within the scope ofthe appended claims.

In accordance with various embodiments of the present invention, themethods described herein are intended for operation as software programsrunning on a computer processor. Dedicated hardware implementationsincluding, but not limited to, application specific integrated circuits,programmable logic arrays and other hardware devices can likewise beconstructed to implement the methods described herein. Furthermore,alternative software implementations including, but not limited to,distributed processing or component/object distributed processing,parallel processing, or virtual machine processing can also beconstructed to implement the methods described herein.

It should also be noted that the software implementations of the presentinvention as described herein are optionally stored on a tangiblestorage medium, such as: a magnetic medium such as a disk or tape; amagneto-optical or optical medium such as a disk; or a solid statemedium such as a memory card or other package that houses one or moreread-only (non-volatile) memories, random access memories, or otherre-writable (volatile) memories. A digital file attachment to email orother self-contained information archive or set of archives isconsidered a distribution medium equivalent to a tangible storagemedium. Accordingly, the invention is considered to include a tangiblestorage medium or distribution medium, as listed herein and includingart-recognized equivalents and successor media, in which the softwareimplementations herein are stored.

Although the present specification describes components and functionsimplemented in the embodiments with reference to particular standardsand protocols, the invention is not limited to such standards andprotocols. Each of the standards for Internet and other packet switchednetwork transmission (e.g., TCP/IP, HTML), and public telephone networks(ISDN, ATM, XDSL) represent examples of the state of the art. Suchstandards are periodically superseded by faster or more efficientequivalents having essentially the same functions. Accordingly,replacement standards and protocols having the same functions areconsidered equivalents.

1. A method of providing access to outgoing call log data associatedwith a plurality of calls made from a user's terminal, the methodcomprising: receiving a request from a web client, the web clientinitiating the request in response to a user's request for access to theoutgoing call log data; initiating and sending a query, to an outgoingcall log database, in response to the request from the web client, andretrieving outgoing call log data corresponding to the user's request inresponse to the query, the outgoing call log database being populatedwith data by interfacing with a network receiving the plurality of callsmade from the user's terminal; sending the outgoing call log dataretrieved from the outgoing call log database to the web client fordisplay; and populating a personal database in the network withinformation sent by the web client, the web client receiving theinformation from a user initiating the user's request, the informationprovided by the user in response to the display of the outgoing call logdata.
 2. The method according to claim 1, wherein the outgoing call logdata is displayed in a Graphical User Interface format.
 3. The methodaccording to claim 1, wherein the first network populates the personaldatabase.
 4. The method according to claim 1, wherein the outgoing calllog data stored in the outgoing call log database comprises: a calledparty number, a start date, a start time, a stop date, and a stop timeassociated with the plurality of calls made from the user's terminal. 5.The method according to claim 4, further comprising determining callduration associated with the plurality of calls made from the user'sterminal.
 6. The method according to claim 5, wherein the outgoing calllog data further comprises the call duration.
 7. The method according toclaim 2, wherein the user makes a repeat call by interacting with theGraphical User Interface.
 8. A method for storing, accessing, anddisplaying outgoing call log data associated with a plurality of callsmade from a user's terminal, the method comprising: storing the outgoingcall log data obtained from an interface server in a first network, theoutgoing call log data comprising call data obtained in response to theplurality of calls made from the user's terminal, and associated,additional information, obtained by the interface server from at leastone of a personal database or a directory database; and sending, inresponse to a web server retrieval request, the outgoing call log datacorresponding to the request, the web server retrieval request being inresponse to a user's request sent from a web client, the web servergenerating a report, based on outgoing call log service privileges, anddisplaying the outgoing call log data corresponding to the user'srequest at the web client; wherein the additional information comprisesa calling party name corresponding to at least a portion of the calldata.
 9. The method according to claim 8, wherein the report isdisplayed in a Graphical User Interface format.
 10. The method accordingto claim 8, wherein the report comprises a summary of calls to aparticular number, charges associated with the calls to the particularnumber, and a proportion of long distance calls to local calls.
 11. Themethod according to claim 8, wherein the outgoing call log serviceprivileges determine a format of the report or information displayed.12. The method according to claim 11, wherein the format is chosen bythe user.
 13. The method according to claim 12, wherein the formatchosen by the user comprises at least one of line graphs, pie charts andbar graphs.
 14. A web server providing access to outgoing call log dataassociated with a plurality of calls made from a user's terminal, theoutgoing call log data comprising call data and associated customizedadditional information, the web server comprising: a web clientinterface for receiving a query from a web client, the web clientinitiating the query in response to a user's request for access to theoutgoing call log data; and an outgoing call log database interface forretrieving the outgoing call log data from an outgoing call logdatabase, the retrieval initiated by the web server in response to thequery from the web client, the outgoing call log database receivingoutgoing call data from at least one of a directory database and adatabase personal to the user; wherein at least a portion of theoutgoing call log data corresponding to the user's request is sent overthe web client interface to be displayed at the web client.
 15. The webserver according to claim 14, wherein the personal database is populatedwith information received from the web client over the web clientinterface.
 16. The web server according to claim 14, wherein the userrequests a repeat call by interacting with the Graphical User Interface.17. The web server according to claim 16, wherein the web serverinitiates a voice over Internet call in response to the user's request.18. The web server according to claim 14, wherein the outgoing call logdata comprises a call start date, a call start time, a call stop date,and a call stop time.
 19. The web server according to claim 14, whereina first network receives the outgoing call data associated with theplurality of calls made from the user's terminal over a data interface,associates the additional information with the call data by querying atleast one of the directory database or the personal database, and storesthe call data and additional information in the outgoing call logdatabase.